Sign in to the docly CLI through the Docly cloud

What you'll see

A push, or any other write, is refused although the folder was unlocked and the same person is signed in:

Error: Refusing to modify this working copy (developers.docly.net): writing is open for developers.docly.net (TuZZ9eKfuU2aBqBzJEL5Aw) on https://docly.net, but this command targets https://cloud.docly.net.

Or the reverse: an agent reads that a site lives on https://docly.net, sees docly status print Server: https://docly.net, and concludes it must sign in there with docly login https://docly.net --direct.

What's actually happening

Docly runs workspaces on several controllers — docly.net, c2.docly.net, c4.docly.net and more. docly login signs in through the Docly cloud unless you pass --direct. The cloud routes each command to the controller that hosts the workspace, so it reaches all of them. A direct sign-in talks to one controller and reaches only the workspaces on that controller.

The working copy still records the controller the folder lives on. That is the Server line in docly status, and it is where the folder is, not where you sign in. Signing in through the cloud is the normal case, not a mismatch to correct.

The unlock is stored together with the endpoint it was opened through. A write is allowed only when the folder is open and was opened through the endpoint the command now goes to. If the folder was unlocked under a direct session and the session is later replaced by a cloud sign-in (or the other way round), every write is refused and nothing is sent. docly unlock with no argument shows the state, including a line such as signed in to https://cloud.docly.net, not https://docly.net, so the server-side opening was not checked.

What to do

• Sign in through the cloud. Run docly login with no --direct. The same session then works for every working copy on every controller, and you never switch sessions to reach another site.
• Do not «fix» a cloud session to match the Server line. The Server line says where the folder lives. Signing in directly there only narrows what the session can reach.
• When a write is refused with this command targets …, the session and the unlock point at different endpoints. The fix is to open the same folder again under the current session — docly unlock <folder guid>, the same folder as before and never a wider one — not to sign in again to match an old unlock. Unlocking is the owner's decision. An AI agent stops and asks, and unlocks only when the owner tells it to, with exactly that scope.
• Check before you write: docly unlock with no argument shows which folder is open, through which endpoint, and whether the opening was checked against the server.
• In agent instruction files, record both facts: the cloud as the sign-in endpoint, and the controller as where the folder lives. An instruction file that lists only Instance: https://docly.net invites an agent to sign in directly.